Add SwiftBuild dlls to cli installer component alongside SwiftPM #417

owenv · 2025-04-29T16:34:28Z

This is my first time touching the windows installer, so there may be some silly mistakes here. Opening the PR now so I can run some tests

platforms/Windows/cli/cli.wxs

compnerd

This change is technically correct and nothing to be done here.

However, because no good deed goes unpunished - looking at this entry makes me wonder if we are building Swift Build properly. Should all these dynamic libraries be dynamic? Would we do better in terms of size and performance to convert some of them to static? I do not have the answer to that, and that is something that requires experimentation. That is something that we should really consider and evaluate (and make the appropriate changes here).

That work however IMO should be a follow up change. Packaging and distributing SwiftBuild as a starting point is the right thing to do.

One final question: should this also go into 6.2?

owenv · 2025-04-29T17:02:54Z

Right now building all the libraries as dynamic simplifies the build by making it easy to ensure we're picking the right linker driver to pull in the c++ stdlib + blocks runtime in the right targets. With some tweaks to swift-driver and general build config cleanup, I think we can gain a lot of flexibility here and experiment with alternate layouts. That said, we've been shipping the fully dynamically linked version on macOS for quite awhile without issues, so I'm not too concerned about perf impact.

One final question: should this also go into 6.2?

I intend to cherrypick to 6.2 but I'd like to make sure this + the SwiftPM changes are working end-to-end on main first

compnerd · 2025-04-29T17:05:14Z

Please do a cross-repo test with building the toolchain for Windows and Windows ARM64 before merging.

owenv · 2025-04-29T21:00:16Z

hmm seeing failures in the cross-repo toolchain build

         C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64\swift-installer-scripts\platforms\Windows\cli\cli.wxs(239): error WIX0150: Undefined preprocessor variable '$(TOOLCHAIN_ROOT)'. [C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64\swift-installer-scripts\platforms\Windows\cli\cli.wixproj]

Which is true, TOOLCHAIN_ROOT isn't on the command line:

  C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\AMD64\MSBuild.exe -noLogo -maxCpuCount -restore C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows\swift-installer-scripts\platforms\Windows\bundle\installer.wixproj -p:WORKAROUND_MIMALLOC_ISSUE_997=False -p:Configuration=Release -p:AndroidArchitectures="" -p:WindowsRuntimeX64=T:\\Program Files\\Swift\\Runtimes\\0.0.0 -p:ImageRoot=T:\\Program Files\\Swift\\ -p:BaseOutputPath=T:\x86_64-unknown-windows-msvc\installer\ -p:ProductArchitecture=amd64 -p:VCRedistDir=C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Redist\\MSVC\\14.42.34433\\x64\\Microsoft.VC143.CRT\\ -p:WindowsRuntimeX86=T:\\Program Files (x86)\\Swift\\Runtimes\\0.0.0 -p:WindowsArchitectures="x86_64;i686;aarch64" -p:Platforms="windows" -p:ProductVersion=0.0.0 -p:WindowsRuntimeARM64=T:\\Program Files (Arm64)\\Swift\\Runtimes\\0.0.0 -p:SWIFT_DOCC_RENDER_ARTIFACT_ROOT=C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows\swift-docc-render-artifact -p:INCLUDE_SWIFT_DOCC=True -p:BundleFlavor=offline -p:SWIFT_DOCC_BUILD=T:\x86_64-unknown-windows-msvc\DocC\release -binaryLogger:T:\x86_64-unknown-windows-msvc\msi\amd64-installer.binlog -detailedSummary:False

owenv · 2025-04-30T15:32:39Z

Think I just needed a rebase, my local checkout was old

owenv · 2025-04-30T23:09:08Z

TOOLCHAIN_ROOT -> ToolchainRoot to align with the changes I rebased on

owenv · 2025-05-01T04:32:50Z

Verified that the toolchains built successfully and can be installed:
https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/5861/
https://ci-external.swift.org/job/swift-PR-build-toolchain-windows-arm64/23/

I can launch SwiftPM without any missing DLL errors, which is a good sign that nothing is broken at runtime. I couldn't test much more than that because swiftc.exe is crashing in mimalloc when compiling manifests:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
  <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" /> 
  <EventID>1000</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>100</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2025-05-01T04:17:48.5571991Z" /> 
  <EventRecordID>4839</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="7872" ThreadID="32036" /> 
  <Channel>Application</Channel> 
  <Computer>OWENVOORHEE74EB</Computer> 
  <Security UserID="S-1[-](https://github.com/swiftlang/swift-installer-scripts/pull/%5Cl%20%22%22)5-21-2521025350-2452346296-830454161-1000" /> 
  </System>
- <EventData>
  <Data Name="AppName">swift.exe</Data> 
  <Data Name="AppVersion">0.0.0.0</Data> 
  <Data Name="AppTimeStamp">6812d77b</Data> 
  <Data Name="ModuleName">mimalloc.dll</Data> 
  <Data Name="ModuleVersion">0.0.0.0</Data> 
  <Data Name="ModuleTimeStamp">6812da2b</Data> 
  <Data Name="ExceptionCode">c0000005</Data> 
  <Data Name="FaultingOffset">0000000000003000</Data> 
  <Data Name="ProcessId">0x727c</Data> 
  <Data Name="ProcessCreationTime">0x1dbba4fee0a32cf</Data> 
  <Data Name="AppPath">C:\Users\ovoorhees\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift.exe</Data> 
  <Data Name="ModulePath">C:\Users\ovoorhees\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\mimalloc.dll</Data> 
  <Data Name="IntegratorReportId">5cadc577-a629-4041-96c2-f300ca1a7d27</Data> 
  <Data Name="PackageFullName" /> 
  <Data Name="PackageRelativeAppId" /> 
  </EventData>
  </Event>

I expect this is probably unrelated to the changes here since the compiler/driver should be unaffected, but I'll see if there's anything I can double-check - any concerns on your end @compnerd?

compnerd · 2025-05-03T22:28:30Z

The invalid memory access is somewhat concerning. There could be something with symbolic resolution that could be going wrong. I think that we should get a backtrace on the invalid memory access and go from there.

owenv · 2025-05-03T23:14:28Z

It looks like the driver is crashing while exec-ing the frontend in mimalloc's atexit handler. This is happening so early in the execution of the driver that heap corruption seems unlikely, but so does a mimalloc bug.

  *** Stack trace for last set context - .thread/.cxr resets it
 #   Arch   Child-SP          RetAddr               Call Site
00    AMD64 00000050`c3efede8 00007ffb`58de8fcc     mimalloc!mi_free+0x30
01  ARM64EC 00000050`c3efedf0 00007ffb`58d25900     ucrtbase!$iexit_thunk$cdecl$d$d+0x1c
02  ARM64EC 00000050`c3efee20 00007ffb`592314e8     ucrtbase!__crt_state_management::wrapped_invoke<void (__cdecl*)(void * __ptr64),void * __ptr64,void>+0x58
03  ARM64EC 00000050`c3efee60 00007ffb`5922fe04     msvcp_win!std::ctype<char>::_Tidy+0x28
04  ARM64EC 00000050`c3efee80 00007ffb`59230330     msvcp_win!std::ctype<char>::~ctype<char>+0x24
05  ARM64EC 00000050`c3efeea0 00007ffb`59239300     msvcp_win!std::ctype<char>::`vector deleting destructor'+0x60
06  ARM64EC 00000050`c3efeed0 00007ffb`592740b8     msvcp_win!std::_Fac_node::~_Fac_node+0x50
07  ARM64EC 00000050`c3efeee0 00007ffb`58d4a348     msvcp_win!std::`dynamic atexit destructor for '_Fac_tidy_reg''+0x28
08  ARM64EC 00000050`c3efef00 00007ffb`58d4a0c8     ucrtbase!<lambda_f03950bc5685219e0bcd2087efbe011e>::operator()+0xe0
09  ARM64EC 00000050`c3efef50 00007ffb`58d49f88     ucrtbase!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >+0x40
0a  ARM64EC 00000050`c3efef90 00007ffb`58d24b20     ucrtbase!#_execute_onexit_table+0x38
0b  ARM64EC 00000050`c3efefc0 00007ffb`5922b8c8     ucrtbase!__crt_state_management::wrapped_invoke<int (__cdecl*)(long * __ptr64),long * __ptr64,int>+0x40
0c  ARM64EC 00000050`c3eff000 00007ffb`5922b2d0     msvcp_win!#__scrt_dllmain_uninitialize_c+0x20
0d  ARM64EC 00000050`c3eff010 00007ffb`5922b11c     msvcp_win!dllmain_crt_process_detach+0x68
0e  ARM64EC 00000050`c3eff050 00007ffb`5922b44c     msvcp_win!dllmain_crt_dispatch+0x5c
0f  ARM64EC 00000050`c3eff060 00007ffb`5922b09c     msvcp_win!dllmain_dispatch+0x13c
10  ARM64EC 00000050`c3eff0c0 00007ffb`5d6c9040     msvcp_win!#_DllMainCRTStartup+0x3c
11  ARM64EC 00000050`c3eff0f0 00007ffb`5d6ba5dc     ntdll!#LdrpCallInitRoutine+0x90
12  ARM64EC 00000050`c3eff140 00007ffb`5d6cbc58     ntdll!#LdrShutdownProcess+0x1bc
13  ARM64EC 00000050`c3eff250 00007ffb`5c95f860     ntdll!#RtlExitU
14  ARM64EC 00000050`c3eff280 00007ffb`58db29d0     kernel32!#ExitProcessImplementation+0x10
15  ARM64EC 00000050`c3eff290 00007ffb`58de877c     ucrtbase!common_exit+0x110
16  ARM64EC 00000050`c3eff2f0 00007ffb`343f4ec2     ucrtbase!$ientry_thunk$cdecl$d$d+0x24
17    AMD64 00000050`c3eff3a0 00007ff6`57ce1ebb     TSCBasic!$s8TSCBasic4exec4path4argss5NeverOSS_SaySSGtKF+0x652
18    AMD64 00000050`c3eff5b0 00007ff6`57ce2ec0     swift!main+0xc0b
19    AMD64 00000050`c3effdc0 00007ffb`5c9df95c     swift!main+0x1c10
1a  ARM64EC 00000050`c3effe00 00007ffb`5c960578     kernel32!$iexit_thunk$cdecl$i8$i8+0x1c
1b  ARM64EC 00000050`c3effe30 00007ffb`5d6cbef0     kernel32!#BaseThreadInitThunk+0x48
1c  ARM64EC 00000050`c3effe40 00000000`00000000     ntdll!#RtlUserThreadStart+0x80

owenv · 2025-05-03T23:15:21Z

Wait, we might be mixing arm and x86 here where we shouldn't be...

jakepetroules · 2025-05-03T23:21:32Z

Wait, we might be mixing arm and x86 here where we shouldn't be...

Just a heads up, if you're saying that because of the "AMD64" and "ARM64EC" in the backtrace, that's expected. All system libraries in Windows 11 are special "ARM64EC" binaries which can be loaded into both arm64 and x86_64 processes. It's kind of like our Universal binaries. Very different, but conceptually similar.

compnerd · 2025-05-03T23:22:15Z

Yeah, ARM64EC seems wrong ...

compnerd · 2025-05-03T23:23:14Z

Wait, we might be mixing arm and x86 here where we shouldn't be...

Just a heads up, if you're saying that because of the "AMD64" and "ARM64EC" in the backtrace, that's expected. All system libraries in Windows 11 are special "ARM64EC" binaries which can be loaded into both arm64 and x86_64 processes. It's kind of like our Universal binaries. Very different, but conceptually similar.

The AMD64 is on our binaries - we are mixing up architectures.

jakepetroules · 2025-05-03T23:34:24Z

But why is that an issue? From what I understood, arm64ec and amd64 are supposed to mix, and a Windows 11 on ARM system contains only arm64ec system dlls.

owenv · 2025-05-03T23:43:54Z

I think this might actually be a CI config issue somewhere, in https://ci-external.swift.org/job/swift-PR-build-toolchain-windows-arm64/23/consoleFull it looks like the job which is supposed to build arm64 toolchains is using x86_64-unknown-windows-msvc everywhere

compnerd · 2025-05-04T17:35:58Z

swift-ci@EC2AMAZ-JCVOGM7 C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64>powershell.exe -ExecutionPolicy RemoteSigned -File C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64\swift\utils\build.ps1 -SourceCache C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows-arm64 -BinaryCache T: -ImageRoot T: -Test lld,lldb,swift,dispatch,foundation,xctest,swift-format,sourcekit-lsp -Stage T:\artifacts -Summary || (exit /b 1 )

This won't cross-compile, you need to do -HostArchName ARM64 for that.

CC: @shahmishal

compnerd · 2025-05-04T17:36:43Z

Let me see if I can do some workarounds in build-windows-toolchain.bat

owenv requested review from shahmishal, compnerd and etcwilde as code owners April 29, 2025 16:34

owenv mentioned this pull request Apr 29, 2025

DNM - toolchain testing swiftlang/swift#79684

Open

compnerd requested changes Apr 29, 2025

View reviewed changes

platforms/Windows/cli/cli.wxs Outdated Show resolved Hide resolved

owenv force-pushed the owenv/add-swiftbuild-libs branch from e4d3a59 to ab10d2d Compare April 29, 2025 16:46

compnerd approved these changes Apr 29, 2025

View reviewed changes

owenv force-pushed the owenv/add-swiftbuild-libs branch from ab10d2d to 2ddf127 Compare April 30, 2025 15:32

Add SwiftBuild dlls to cli installer component alongside SwiftPM

dca65b9

owenv force-pushed the owenv/add-swiftbuild-libs branch from 2ddf127 to dca65b9 Compare April 30, 2025 23:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add SwiftBuild dlls to cli installer component alongside SwiftPM #417

Add SwiftBuild dlls to cli installer component alongside SwiftPM #417

owenv commented Apr 29, 2025

compnerd left a comment •

edited

Loading

owenv commented Apr 29, 2025

compnerd commented Apr 29, 2025

owenv commented Apr 29, 2025 •

edited

Loading

owenv commented Apr 30, 2025

owenv commented Apr 30, 2025

owenv commented May 1, 2025

compnerd commented May 3, 2025

owenv commented May 3, 2025

owenv commented May 3, 2025

jakepetroules commented May 3, 2025

compnerd commented May 3, 2025

compnerd commented May 3, 2025

jakepetroules commented May 3, 2025

owenv commented May 3, 2025

compnerd commented May 4, 2025

compnerd commented May 4, 2025

Add SwiftBuild dlls to cli installer component alongside SwiftPM #417

Are you sure you want to change the base?

Add SwiftBuild dlls to cli installer component alongside SwiftPM #417

Conversation

owenv commented Apr 29, 2025

compnerd left a comment • edited Loading

Choose a reason for hiding this comment

owenv commented Apr 29, 2025

compnerd commented Apr 29, 2025

owenv commented Apr 29, 2025 • edited Loading

owenv commented Apr 30, 2025

owenv commented Apr 30, 2025

owenv commented May 1, 2025

compnerd commented May 3, 2025

owenv commented May 3, 2025

owenv commented May 3, 2025

jakepetroules commented May 3, 2025

compnerd commented May 3, 2025

compnerd commented May 3, 2025

jakepetroules commented May 3, 2025

owenv commented May 3, 2025

compnerd commented May 4, 2025

compnerd commented May 4, 2025

compnerd left a comment •

edited

Loading

owenv commented Apr 29, 2025 •

edited

Loading